The present invention relates to methods and devices that support mobility of a client across a campus, particularly mobility across VLANs and subnets, while preserving the client's assigned IP address. Both layer 2 and layer 3 packets are supported. Layer 2 and 3 refer to the OSI seven-layer model. Mobility support most clearly applies to wireless clients, but could apply to other kinds of mobile connections, even to wired connections.
As computers become more ubiquitous and all of us spend more time using our computers, we personalize or customize them and come to depend on the particular environment that we create. Improvements in portable devices encourage us to carry along our custom environments, moving from place to place with a laptop under our arm.
Concurrently, the extended reach of networks across campuses, into meeting places, coffee houses, hotels, airports and elsewhere has encouraged development of IP-based devices, such as voice over IP (VOIP) telephones and, particularly, wireless IP devices, such as IEEE 802.11 conforming and Bluetooth VOW telephones and PDAs. The new devices tend to move with us.
The Mobile IP Working Group of the Internet Engineering Task Force has made extensive efforts to standardize protocols for device mobility. RFC 3344 sets forth an elaborate standard that may some day be widely implemented, but it is not presently. Implementation will require support from operating system vendors and others. It may prove impractical for some mobile devices that have modest processing capabilities, such as WLAN VoIP telephones and PDAs, ever to implement the standards. Widespread implementation seems to be years away.
At least two special cases of mobility exist, based on current infrastructures. In one case, a user moves from one subnet to another, while moving from one subnet gateway to the next. The new gateway does not host the original subnet. In another, the user moves from an original VLAN to a new VLAN, for instance going from an original access point to a new access point. The gateway may or may not change. These cases present different problems because of the different network access protocols involved.
An opportunity arises to develop mobility support that is transparent to existing devices, that does not require rewriting the kernel or stack to support a new IP architecture, and responds to mobility without changing the client machine's assigned IP address. It is bound to be easier to add features to devices that support mobility across a campus than to change all of the devices that users carry. Better, more easily configured and controlled, more resilient and transparent components and systems may result.